<html><body><pre>

Transport Layer thought

1) Capability : several implementation for the transport layer
->connected
->datagram

2) Physical endpoint definition for peers
->define for local: guess capability of connection of local peer
->handle for remote: be able to connect to any peers having a definition
->2 endpoint defs for each peers, connected and remote

3) Discovery
->because DHT is the discovery, it has a special role
->if udp connectivity: native
->else, proxied

-> the transport layer should be the hoster and the interface implementor API wise, can host several type of algs...

Objects:

- 2 different interfaces, for connected and datagram
- DHT interface also
- endpoint interface is encodable and located in peers, can be exchanged, persisted
- peers can have no endpoint at a time, or only the datagram endpoint, or full endpoints
- connected transport layer may requires both keys and endpoint to connect, connectionless cannot : it must be possible to retrieve the key from an endpoint via connectionless
- if a protocol implements both datagram and connection, connection endpoint may be empty.

Flux:

init:
- ask for endpoint of self
- all protocol implementation should add their endpoint to "self"
- publish that in the discovery

Send a datagram message:
- get the target endpoint from the target peer (in the target peer the key may be unknown)
- locate the corresponding protocol implem.
- forward the send request with the local key

Receive a datagram message:
- build the remote endpoint from the message
- build the remote key from the message
- find/build the remote peer with (this endpoint+key) from the peer manager
- forward (received message+remote peer) to listeners

Open a connection:
- get the remote endpoint. If the remote peer does not have yet a connection-wise endpoint, use the datagram-wise endpoint to exchange hello messages and retrieve full peer definition
- locate the corresponding protocol implem.
- forward the open connection request

incoming connection:
- negociate hello messages: get key and all endpoints for the remote peer
- find/build the remote peer with (endpoint + key) from the peer manager
- forward incoming (connection+peer) to listeners

DHT:
- DHT can only use datagram protocol
- if datagram protocol is not available natively (i.e. UDP connection), DHT is proxied to a DHT enabled host
- Because DHT is datagram protocol, DHT publish datagram endpoints automatically to all contacted remote peers
    -> DHT is proxiable, so DHT hoster is the datagram protocol

Discovery with DHT:
- Via DHT.locale (KeyBasedRouting), we find the datagram endpoint of any peer via his key
- send hello request, awit for response, fill all endpoints

discovery via endpoint:
- need a connectionless endpoint
- send hello request, wait for response, fill all endpoints

</pre></body></html>
